As networks have grown in size, the networks have become more difficult to manage (ie. monitor and maintain). It was determined that a network management protocol needed to be developed. A protocol initially developed as a quickly designed "temporary" solution to management difficulties was designated simple network management protocol (SNMP). Although improvements have been made to the original SNMP, improvement protocols, such as SNMPv2, still embody many of the essential features of the original SNMP.
While SNMP was designed as a temporary answer to communications problems between different types of networks, no better choice became available and SNMP became the network management protocol of choice. As a result, a large number of network entities (NE) are designed to be SNMP compliant. That is the NE acts as an agent that can receive messages from a network manager and supply responses to the received requests. These network information exchange messages are known in the art as protocol data units (PDUs).
Although there are several types of PDU messages, this invention is concerned with trap messages that are initiated by agents and are used for monitoring various network events such as terminal start-ups, shut-downs and other entity, typically software, events. In many instances, when such a trap message is received by a manager, an error defining message is displayed on a monitor in human readable form so that suitable action may be taken where action is appropriate.
If an NE is not designed as a SNMB compliant entity, the trap event or error messages must be translated to a common format that the SNMB managers can correctly interpret. An SNMP manager may be required to interact with many types of NEs such as routers, servers, repeaters and the like. The trap message is coded so as to be very compact and thus PDUs from two different NEs that appear to be identical may be indicative of entirely different events. To this end, a plurality of trap definitions are incorporated in management information bases (MIBs) that are used by a manager to correctly interpret the trap message being received. Typically a manager accesses a different MIB for each different type NE.
The writing of an MIB is a tedious process that requires one to follow a very stringent set of rules in developing the definition. For an NE that has many events that need to be monitored, the manual preparation of such a file takes thousands of hours. Since an SNMP manager will totally reject an MIB file that incorporates any type of format or syntactical error, many additional hours are often required to debug a defective MIB.
It would thus be desirable to be able to automatically generate an MIB having trap definitions for each of the alarms or logs for which trap messages are to be supplied by a given NE wherein the MIB is free of format or syntactical errors.
Sometimes an entity requires monitoring of new events or presently monitored events may require assignment of different interpretations. In such instances, it would be desirable to generate a new MIB with a minimum of effort and replace the MIB file in the appropriate SNMP managers.